home *** CD-ROM | disk | FTP | other *** search
/ Hackers Underworld 2: Forbidden Knowledge / Hackers Underworld 2: Forbidden Knowledge.iso / HACKING / ISSM302.TXT < prev    next >
Text File  |  1994-07-17  |  23KB  |  311 lines
  1.  
  2. Story #1
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14. Volume 3 Number 2                                                                                                     April 1993
  15.  
  16. Story #2
  17. In This Issue
  18.  
  19. NLM Anti-Virus
  20. Review Team
  21.  
  22. Virus Alert Retraction
  23.  
  24. Password Tokens
  25.  
  26. Clyde's Computer Security Hall of Fame
  27.  
  28. Dear Clyde
  29.  
  30. DSA Security Awareness Newsletter
  31.  
  32. Proposed Training
  33.  
  34. FCC's Rules Affecting Fax Service
  35.  
  36. Computer Speak
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44. The ISSM is a quarterly publication of the Department of Treasury, Bureau of the Public Debt, AIS Security Branch, 200 3rd Street, Parkersburg, WV 26101  (304) 420-6368
  45.  
  46. Editors:   Ed Alesius
  47.               Kim Clancy
  48.               Joe Kordella
  49.               Jim Heikkinen
  50.               Mary Clark
  51.  
  52.  
  53.  
  54.  
  55. Story #3
  56.  
  57. NLM Anti-virus review team            
  58.  
  59.  
  60. Story #4 -- "VIRTEAM"
  61. In 1992, Public Debt was hit with its first virus.  As a result it was decided that an anti-virus plan was needed.  The plan would consist of assigning responsibilities in the area of preventing viruses from being introduced, recovering once they had been discovered, purchasing software to accomplish this task, and installing it on Public Debt's local area network (LAN) servers to aid in the detection of viruses once they were introduced.
  62.    Currently, the AIS Security Branch has installed scan and detect programs to run consistently on every server connected to Public Debt's LAN.  This requires a dedicated PC running scan software and another to run detection software at each Public Debt location, those locations being: E Street, C Street, Parkersburg Main Building and Town Square.
  63.    A new technology was developed that would significantly enhance the integrity of Public Debt's LAN anti-virus program.  This technology enabled an anti-virus tool to reside and operate on a Novell server instead of operating off of DOS.  This provided additional functionality not possible with a DOS-based protection scheme.  For example, a Netware Loadable Module (NLM) could sit on a server and scan a file everytime it was uploaded or downloaded to the server.  A DOS-based product would not be able to di
  64.  
  65. stinguish this activity, therefore, it would be unable to perform the scan at that time.
  66.    The AIS Security Branch was assigned the responsibility of reviewing NLM anti-virus products and reporting on their feasibility for Public Debt.  As a result, a team was developed, a testing plan was agreed upon,NLM anti-virus products were procured,  tested, and a recommendation was made.  The following will outline the details of the team and the testing.
  67.    The Public Debt LAN is made up of a myriad of platform configurations.  Most of our servers run Novell software, but the versions of the software vary.  A portion of the LAN is run on an OS/2 platform and currently is running an OS/2 based virus protection package.  The OS/2 LAN was not  included in the scope of the review in that it will be replaced in the near future and current protection techniques that are being performed at a server level are adequate.
  68.    The NLM review team was comprised of individuals that could represent the different environments throughout Public Debt.  The team members are as follows:
  69.      OAIS/AIS Security Branch: Kim Clancy        (team leader), Jim Heikkinen, Mary              Clark, Joe Kordella
  70.      OA/TSS:  Dee Atwell, Bill Scroggs
  71.      OAIS/Communications Branch:  Rick            Montalbano
  72.      OA/OAB:  Jeff Schaff, Chris Murnahan
  73.      SBOO/OAB:  David Earley
  74.      OAIS/SEAS:  Conrad Sterling
  75.    The test plan was the process that was developed and followed by the team to ensure that consistent testing was accomplished.  The steps that were agreed upon are as follows:
  76.      1. Requirements for the software were agreed upon.  A rating sheet was developed and utilized in the evaluation of the anti-virus software.
  77.      2. A market survey was conducted and a list of products was presented to the team.  
  78. The team selected several software packages for evaluation that appeared to best fit the needs of the Bureau.
  79.      3. A procurement for the software was initiated and assignments were made to team members defining the product they would be responsible for demonstrating.
  80.      4. Software was received and distributed to team members who were given time to utilize the products, become familiar with them and able to demonstrate them against the testing criteria developed.
  81.      5. The team met, reviewed and rated the software and agreed upon recommendations.
  82.    All software packages that meet the Bureau's requirements will be submitted as acceptable for purchase.  After a tool has been procured, the NLM review team will develop configuration standards and implement the product Bureau wide.
  83.  
  84.  
  85. Story #5
  86. Dear Clyde
  87.  Responses to 
  88.  questions for
  89.  those who are
  90.  searching for
  91.  the truth.
  92.  
  93.  
  94.  
  95. Story #6
  96.     April 1993                                                          ISSM                                Page 4                        Page 4
  97.    
  98.  
  99.  
  100. Story #7
  101.   April 1993                                             ISSM                                                               Page 3
  102.  
  103.  
  104. Story #8
  105.  
  106.  
  107.                            
  108.     ISSM
  109.  
  110. Story #9
  111. Information
  112.  
  113.  
  114.  
  115. Story #10
  116. Systems
  117.  
  118.  
  119. Story #11
  120. Security
  121.  
  122.  
  123. Story #12
  124. Monitor
  125.  
  126.  
  127. Story #13
  128. Dedicated to
  129.  
  130.  
  131. Story #14
  132.      the pursuit
  133.  
  134.  
  135. Story #15
  136.        of security
  137.  
  138. Story #16
  139.   awareness
  140.  
  141.  
  142. Story #17
  143.     April 1993                                                ISSM                                                     Page 2         
  144.  
  145. Story #18
  146. Send your comments or questions to Clyde c/o the AIS Security Branch in Parkersburg, Room 1011, or leave them in Clyde's mailbox located on the Security bulletin boards throughout the Parkersburg office.
  147.  
  148.  
  149. Story #19 -- "NWSLTR04.03"
  150. In the not too distant future, Public Debt will be providing  Password Generating Tokens to its mainframe computer users.  These tokens will provide an additional level of computer security access control to help insure that the Bureau's computer systems are kept secure.  We will be publishing various articles regarding tokens so that you can become aware of what these tokens are, how you use them, etc.  The first of these articles "A decade of experience with password tokens" follows. It is an excellent ar
  151.  
  152. ticle that appeared in the January/February 1993 issue of the Infosecurity News.  This article by Ben Miller, who is editor/publisher of Personal Identification Newsletter in Rockville, Md. He chairs the annual CardTech / SecurTech Conference. This article is reprinted by permission of Infosecurity News.
  153.  
  154.    It is hard to believe that 10 years have passed since password tokens were first introduced to the information security world.  At the start, the technology was too complicated for most users to understand, the tokens were notoriously unreliable and only a few operating environments supported the technology.
  155.    Somewhere along the line, however, tokens took off.  Now, more than 2,000 organizations use these personal authentication devices and some have more than 10,000 units in circulation.
  156.    In the U.S. alone, more than half a million people use tokens to access computers.  This adds up to a lot of experience, which is increasingly reflected in the sophistication of the newest hardware and software offered by suppliers.
  157.    At first glance, a typical password token looks like a pocket calculator (although it may have only a few keys) and has about the same dimensions as a stack of three or four credit cards.  The device generates and displays a different password each time its owner logs on.
  158. Industry structure
  159.    There are two major components to what is called the enhanced user authentication market--the tokens themselves and the host interfaces that support them.  Unfortunately, vendors do not neatly fall into these two categories.  While firms that produce tokens offer host support for their own devices, not all support competitors' tokens.  Other companies, including some suppliers of host access control packages, offer hostsoftware or hardware front-ends